A Wireless/Wired Sensor and Actuator Network (WSAN), is a wireless/wired network of sensors and actuators, such as e.g. smoke detectors, water leak detectors, temperature sensors, humidity sensors, pressure sensors, vibration sensors, light sensors and light switches, to be deployed e.g. in a household or a car. The services of the WSAN are available remotely via a WSAN Gateway connected to a WAN (Wide Area Network), using a standardized communication protocol, e.g. the Ethernet or HTTP/SOAP, and another communication protocol, e.g. ZigBee, is used internally within the WSAN.
FIG. 1 illustrates a typical WSAN system, in which a number of WSAN sensors or actuators are connected via wire or radio in a single star or mesh topology to one or more WSAN Gateways which are connected to a WAN (Wide Area Network). The figure shows two WSANs, 12a , 12b , each WSAN connected to a WAN 14 via a WSAN Gateway, 15a , 15b , and comprising five sensors or actuators. The WSANs are available to the WAN users 11a, 11b via the WSAN Gateways, and the WSANs are operated via a WSAN Manager 16 by a WSAN operator 13.
Since a typical sensor is a simple embedded device that cannot be connected directly to a user or to an application in the WAN for security reasons, a WSAN Gateway acts as a mediator between the sensor nodes and the users/applications outside the domain of a WSAN. The WSAN Gateway is also capable of offering more sophisticated services than a single sensor node can offer. In a WSAN deployed in a house with several rooms, each room provided with a separate temperature sensor of the WSAN, the WSAN Gateway may provide e.g. the average temperature of the house to an external application, as well as the reading of the separate temperature sensors in the rooms. In order to provide this service, the WSAN Gateway requires suitable protocols and interfaces for requesting individual temperature readings from each sensor, and for presenting raw or aggregated data, such as the average temperature, in a format that is readable by the requesting application.
Thus, a WSAN Gateway requires a standardized data representation, as well as standardized interfaces with the various applications in a WAN. Additionally, the specific needs of business enablers have to be fulfilled in order to make commercial WSANs successful. The conventional Semantic Web Technology provides a standardized data representation, as well as a part of a standardized interface, and a WSAN Gateway using the Semantic Web Technology accesses individual sensors by using a standardized interface and maintains sensor data tagged with semantic metadata describing the meaning of the sensor data. Further, the WSAN Gateway uses a semantic web representation as an interface to the WSAN users and the WAN applications. The combination of the real sensor data and the semantic metadata forms a sensor data Ontology and sensor data Instantiation.
FIG. 2 illustrates an Ontology 21, according to the conventional Semantic Web Technology, the illustrated Ontology 21 representing a sensor node having a temperature sensor providing temperature readings in the Celsius scale, as well as an Instantiation 22 of the Ontology 21. Said Instantiation 22 comprises an identification of the real sensor, TempSensor1345, and well as a sensor measurement, 27.5 , produced by the sensor, and the sensor identification and the sensor measurement are both linked to the Ontology 21, as illustrated by the arrows in FIG. 2. Thus, the Instantiation 22 indicates the identity of a specific temperature sensor, as well as the output from the temperature sensor, while the Ontology 21 describes how the constants of the Instantiation 22 are connected.
The WSAN Gateway has to be able to interact with each individual sensor attached to the WSAN, and a new sensor, not previously connected to the WSAN Gateway, has to be authenticated after insertion in the WSAN. The WSAN Gateway has to obtain the private identity, ID_S, of a new sensor, the service description, suitable drivers and gateway software, as well as the data representation of a new sensor to be able to interact with the sensor. The Ontology 21 and the Instantiation 22 illustrated in FIG. 2 show a data representation of an actual temperature sensor, but the actual mechanism of obtaining the identity of the sensor (TempSensor1345) and the sensor value (27.5) is not defined by the Ontology.
Currently, no automatic and secure method is available for attaching a new sensor to a WSAN and enabling updating of a WSAN Gateway with the service description, the software and the drivers for the new sensor, since a conventional commercial sensor has no software, or is a part of a closed WSAN system, to which no sensors should be added. Instead, sensor software and hardcoded descriptions of the data and the services offered by the sensor have to be developed specifically for the WSAN Gateway when a new sensor is added to a WSAN.